Subject: Week 3's agenda and proposed work and flow diagrams

From: alan bartky <[email-masked]>
Date: Mon, 19 Jul 93 11:47:40 PDT

Fellow Connect/Disconnectors:

We are now on our third week.  It is now time to start focussing our
discussions and to get some "formal" submissions from members on connect/
disconnect sequence flows and state machines.  Here is the remaining agenda:

This Week:

7/19-23 Email Discussions of Formal Proposals.  Goal to reach
        consensus on basic technical methods proposed and start of 
        detailed work on working group document for connect/disconnect
        sequences.  Edited Formal Submissions (based on comments) to be
        submitted.

Remaining work:

7/26-30 Final discussions on proposals.  Goal to have first draft document
        by Friday.

8/2-6   Discussion/ Comments on first draft of Connect/Disconnect document.
        Technical, Editorial, Content.  New submissions to be additions
        changes to the document.  Goal to have second draft document
        by Friday.

8/9-13  Discussions/Comments on Second Draft Documents.  New submissions 
        at this point should be only to aid in completion or clarification
        of the work in progress.  Goal to have review copy of final Draft 
        by Friday.

8/16-20 Discussions on Final Draft.  Changes to the document should
        be editorial in nature.  Edited final draft ready to go by Friday.

8/23-27 Final Discussions, Document submitted to the AIW.  (Note: This
        is also the week of fall Interop).

8/30-9/3 Initial feedback from the AIW (non connect/disconnect members)
        Answers from Group members to the AIW.  Any discussion within
        working group as needed.  Blatant errors (editing or technical)
        to be corrected by group consensus.  Any final changes to be
        resubmitted to AIW by Friday.  (NOTE:  THIS IS THE TWO WEEK
        FINAL DEADLINE PRIOR TO THE NEXT AIW).

9/6-17  (Two weeks)  Open discussion period, Questions/Answers to rest of
        AIW.  Any proposed changes to the document will be logged and 
        presented in open forum at the AIW.

9/21-23 AIW Meeting, Raleigh NC.

As far as adding QLLC to the agenda (as proposed by Bernard Brady and others)
I gave the idea of supporting QLLC over the weekend and I have the following
comments.

Regarding SNA/LLC to SNA/QLLC, the LLC station only knows about MAC
addresses and cannot be configured for X.25 DTE addresses.  The same
is true for SNA/SDLC and even routers which make their decisions to
route based on MAC addresses, SAPs, etc.  It is therefore necessary for
an SNA/LLC or SNA/SDLC to SNA/QLLC converter to match (connect) SDLC or
LLC2 link stations to QLLC calls.  I do not think that DLSw should perform
this function and should remain only knowledgeable about MAC addresses and
SAP addresses.  If an SNA/LLC to SNA/QLLC function is desired for a DLSw
connection (circuit), then the MAC/SAP address to X.25 QLLC Circuit
mapping should be done in the remote router and not involve the DLSw
protocol.  The only thing that I could think of as far as QLLC was concerned
was that it would be easier for a DLSw to QLLC gateway if the existing
method of using the initial TEST or XID to establish the circuit would be
used.  This would allow the circuit ID to match to an X.25 QLLC circuit and
then for the XID DLSw messages to map to the QLLC Qualified Data XID 
messages.

If QLLC is to added to this group, then the only way it will be added is
by submitting proposals and having the group come to consensus.  We can't
just say "wouldn't it be nice if we could have SNA/LLC talk to SNA/QLLC
using DLSw as a transport connection", we need concrete proposals.  We have
enough work as it is, so if QLLC is to be added, let's see some proposals,
otherwise It will be dropped.

As far as our mainline problem of solving connect and disconnect sequences,
we need to get going on getting some real proposals going on how
to make this protocol work.  Here's what I propose to use for discussing
different methods (challenge for the week):

Come up with a proposal that will handle the following flows, provide
detail for the middle that will work under the various cases:

SDLC <----> Network <-> SDLC
SDLC <----> Network <-> LLC
LLC <-----> Network <-> SDLC
NETBIOS <-> Network <-> NETBIOS

For SNA both PU 2.0 and PU2.1 cases will be worked on (any opinions on
supporting other PU types?)

My proposal is to attack the problem by working on flow diagrams of
end systems, and work out what happens in the "middle".  These diagrams
will consist of ASII pictures (simple arrows and text) with corresponding
text messages.

These are the first two cases I would like to start work on:


Case 1: SNA/LLC to SNA/LLC (Example Typical PU 2.0 connect sequence)

Station 1                       Network         Station 2        

TEST CMD (D=4,S=0)              Ignore
--------------------->
(Note 1)

TEST CMD (D=4,S=0)             ????????          TEST CMD (D=4,S=0)
--------------------->   -------------------->  ---------------------->
(Note 2)

TEST RSP (D=0,S=4)              ????????         TEST RSP (D=0,S=4)
<---------------------   <--------------------  <----------------------
                                                 (Note 3)

Null XID CMD (D=4,S=4)           ????????        Null XID CMD (D=4,S=4)
--------------------->   -------------------->  ---------------------->
(Note 4)

Null XID CMD (D=4,S=4)          ????????         Null XID CMD (D=4,S=4)
<---------------------   <--------------------  <----------------------

P2.0 XID RSP (D=4,S=4)           ????????        P2.0 XID RSP (D=4,S=4)
--------------------->   -------------------->  ---------------------->
(Note 5)

SABME CMD (D=4,S=4)             ????????         SABME CMD (D=4,S=4)
<---------------------   <--------------------  <----------------------
                                                (Note 6)

UA RSP (D=4,S=4)              ????????           UA RSP (D=4,S=4)
--------------------->   -------------------->  ---------------------->

Note 1: This is a "local" test message (no routing information) and
would only apply to token ring networks.  For ethernet networks, only
"local" test messages would be used, so this would have to cause the sequence
to start.

Note 2: This is the Broadcast test frame using either single route or
or all routes broadcast.  Remember that the SNA station may be downstream
past several bridges and the DLSw switch may receive more than one TEST
command for the same session (you have to key off the MAC SAP address).

Note 3: This is a either a non broadcast response (if all routes was used
in the command) or an all routes broadcast respones (if single route
broadcast was used in the response).  Remember that again several TEST
responses may be received, due to multiple paths due to other bridges and/or
routers.

Note 4: This is a source routed non-broadcast "Null" XID, in this case the
source SAP does equal the destination SAP.

Note 5: This is the PU2.0 XID with the ID NUM and ID BLK (8 digit) PU
2.0 used by the front end's Switched Major Node Table (or by other gateway
device to identify the PU).

Note 6: This is the SABME command to establish the LLC type 2 connection.
There has been some discussion on whether or not the UA should be
sent immediately (with a corresponding RNR frame), or is held off until
the circuit is established (thus no RNR frame needed, this of course
would assume that the XID and TEST frames would be sent without
first establishing a circuit).


Case 2: SNA/LLC to SNA/LLC (Unequal DSAP and SSAP values)

Station 1                       Network         Station 2        

TEST CMD (D=4,S=0)              Ignore
--------------------->
(Note 1)

TEST CMD (D=4,S=0)             ????????          TEST CMD (D=4,S=0)
--------------------->   -------------------->  ---------------------->
(Note 2)

TEST RSP (D=0,S=4)              ????????         TEST RSP (D=0,S=4)
<---------------------   <--------------------  <----------------------
                                                 (Note 3)

Null XID CMD (D=4,S=8)           ????????        Null XID CMD (D=4,S=8)
--------------------->   -------------------->  ---------------------->
(Note 4)

Null XID CMD (D=8,S=4)          ????????         Null XID CMD (D=8,S=4)
<---------------------   <--------------------  <----------------------

P2.0 XID RSP (D=4,S=8)           ????????        P2.0 XID RSP (D=4,S=8)
--------------------->   -------------------->  ---------------------->
(Note 5)

SABME CMD (D=8,S=4)             ????????         SABME CMD (D=8,S=4)
<---------------------   <--------------------  <----------------------
                                                (Note 6)

UA RSP (D=4,S=8)              ????????           UA RSP (D=4,S=8)
--------------------->   -------------------->  ---------------------->

Note 1: This is a "local" test message (no routing information) and
would only apply to token ring networks.  For ethernet networks, only
"local" test messages would be used, so this would have to cause the sequence
to start.

Note 2: This is the Broadcast test frame using either single route or
or all routes broadcast.  Remember that the SNA station may be downstream
past several bridges and the DLSw switch may receive more than one TEST
command for the same session (you have to key off the MAC SAP address).

Note 3: This is a either a non broadcast response (if all routes was used
in the command) or an all routes broadcast respones (if single route
broadcast was used in the response).  Remember that again several TEST
responses may be received, due to multiple paths due to other bridges and/or
routers.

Note 4: This is a source routed non-broadcast "Null" XID, in this case the
source SAP does not equal the destination SAP (and from previous
discussions might cause problems with the current DLSw (any comments IBM?)).

Note 5: This is the PU2.0 XID with the ID NUM and ID BLK (8 digit) PU
2.0 used by the front end's Switched Major Node Table (or by other gateway
device to identify the PU).

Note 6: This is the SABME command to establish the LLC type 2 connection.
There has been some discussion on whether or not the UA should be
sent immediately (with a corresponding RNR frame), or is held off until
the circuit is established (thus no RNR frame needed, this of course
would assume that the XID and TEST frames would be sent without
first establishing a circuit).


Those are the 1st two, I will provide the other SNA flows if the group
decides that this is a good way to discuss flow in order to drive towards
a real solution (if someone could volunteer ASCII text NETBIOS flows
it would be appreciated).  I know that ASCII messages are a pain, but
they are much easier to mail and distribute, and I think we can use ASCII
text "arrows" with coressponding text descriptions and state machine 
tables.

Lets' get started on the nitty gritty.

Regards,
Alan

---

From: Bernard Brady <[email-masked]>
Date: Thu, 22 Jul 93 12:05:46 EDT

Alan,

In trying to understand the SSP messages associated with the flow
diagrams you presented I am confused on the actual Data Link and Circuit
IDs that are being used in establishing both circuits and connections. 

>  LAN                                            DLS Origin/Target                                LAN
>TEST CMD (D=4,S=0)             CANUREACH(Data Link ID)          TEST CMD (D=4,S=0)
>TEST RSP (D=0,S=4)             ICANUREACH(Data Link ID, Target Circuit ID)    	 TEST RSP (D=0,S=4)
>					        REACH_ACK(Data Link ID, Origin Circuit ID, Target Circuit ID)    
>							------------------------->	
> Circuit Est.
>				
>Null XID CMD (D=4,S=4)     XID(Data Link ID, Origin Circuit ID, Target Circuit ID)   Null XID CMD (D=4,S=4)
>Null XID CMD (D=4,S=4)     XID(Data Link ID, Origin Circuit ID, Target Circuit ID)		Null XID CMD (D=4,S=4)
Since the Data LINK ID contains the Origin and Target Link SAP
I take it that this flow is mapping S=4 to S=0 over the established
circuit above?  This will work except in the case where you receive
multiple XID's as shown below.

>Null XID CMD (D=4,S=4)          ????????         Null XID CMD (D=4,S=4)
How is this mapping occuring, are the same Origin and Target Circuit IDs
being used and the Data Link IDs reflect the true Origin and Target
SAPs.  If this is true then  what values are used in
the CONTACT/CONTACTED messages below?

SABME CMD (D=4,S=4)             CONTACT(?)     SABME CMD (D=4,S=4)
<---------------------                         <-------------        <----
SABME CMD (D=4,S=8)             CONTACT(?)     SABME CMD (D=4,S=8)
<---------------------                         <-------------        <----

 UA RSP (D=4,S=4)              CONTACTED(?)          UA RSP (D=4,S=4)
--------------------->                         --------->          ------>
UA RSP (D=8,S=4)              CONTACTED(?)          UA RSP (D=8,S=4)
--------------------->                         --------->          ------>

---

From: Bernard Brady <[email-masked]>
Date: Thu, 22 Jul 93 09:43:15 EDT

Alan,

In looking at these flows and IBM documentation it seems that  a TEST or
XID could be used for route discovery.  Should these also be included in
the flow or was there a reason that they were left out?

Bernie

                                                 (Note 3)

By reading the IBM manuals it seems that this is also possible on route
discovery and should be included.  This would be treated like the TEST
frames above.  Is this really ever done in the real world?

XID CMD (D=4,S=0)             ????????          XID CMD (D=4,S=0)
--------------------->   -------------------->  ---------------------->

XID RSP (D=0,S=4)              ????????         XID RSP (D=0,S=4)
<---------------------   <--------------------  <----------------------

>Null XID CMD (D=4,S=4)           ????????        Null XID CMD (D=4,S=4)

Same issue as stated above.

XID CMD (D=4,S=0)             ????????          XID CMD (D=4,S=0)
--------------------->   -------------------->  ---------------------->

XID RSP (D=0,S=4)              ????????         XID RSP (D=0,S=4)
<---------------------   <--------------------  <----------------------